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DETAILED ACTION 

Response to Arguments 

1 . Applicant's arguments, see pre-appeal brief, filed 4/26/10, with respect to claims 
1,2,4, 5, 7-1 1 , 1 3, 1 5-1 7, 20-25, 27, 31 , 33-35, and 37 have been fully considered and 
are persuasive. Therefore, the rejection has been withdrawn. However, upon further 
consideration, a new ground(s) of rejection is made in view of Davies (US 7,043,749). 

2. Applicant's request for reconsideration of the finality of the rejection of the last 
Office action is persuasive and, therefore, the finality of that action is withdrawn. 

Claim Objections 

3. Claims 1,13, 27, and 34 are objected to because of the following informalities: 
All these claims state the packet stream is transmitted over a constant delay, reliable 
transmission channel, but the system adjust packet stream transfer delay, which means 
the delay is not constant. Appropriate correction is required. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 
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5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 148 
USPQ 459 (1966), that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

6. Claims 1,2,4, 5, 7-8, 13,15, 20-22, 27, 31 , 33-35, and 37 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Harumoto et al. (US 2002/0004840) in view 
of Colavito et al. (US 20030152094) and Davies (US 7,043,749). 

With regard to claim 1 , Harumoto et al. teaches (see figures 3, 9, and 12): A 
method for receiving a packet stream at a client, comprising: estimating packet stream 
transfer delay variation (calculating TS), estimating parameters of a jitter buffer 
(reception buffer, 505) based on the packet stream transfer delay variation (calculates 
delta which is buffer occupancy at varies TS times: see figure 9, paragraphs 1 74-1 78); 
and transmitting to the server information indicative of an aggregate of the pre-decoder 
buffering parameters (decoder buffer, 508)and the jitter buffer (See steps 301 in figure 
12, discussed in paragraph 182; wherein the terminal calculates (estimates) its own 
buffer occupancy and then sends its sum of its occupancy to the server. Also, Harmoto 
teaches in figure 21 B (see paragraphs 17-19), how the buffer occupancy is based of the 
amount of data in the video/decoder buffer + reception buffer. ). 

Harumoto fails to disclose that packet stream transfer delay variation indicative of 
a variation time for transferring of the packet stream from the server to the client. 
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However Colavito teaches an adaptive jitter buffer management system that 
updates the buffer threshold by calculating the average packet transit time over the 
network and uses that information to determine the jitter in the network in order to 
reduce playout delay and improve quality of service (see abstract and figure 5, steps 
506-512.). 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to have the client/terminal determine the average (estimate) 
packet transmit time over the network (from server to client) as taught by Colavito in the 
transmission/reception module of Harumoto in order to reduce playout delay and 
improve quality of service. 

Harumoto and Colavito fails to disclose receiving from a server pre-decoder 
buffering parameters to ensure that the client is able to play out the packet stream 
without buffer violation when the packet stream is transmitted over a constant delay, 
reliable transmission channel. However, Harumoto teaches how the client knows that 
decoder buffer size is 224 Kbytes and it must have uses a vbv delay in order to play the 
video on the client at a constant rate (paragraphs 8-1 1 ), but it fails to teach the client 
knows this information about the decoder buffer. 

Davies teaches a gateway that sends video delay information to a terminal and 
the terminal returning back transit (jitter) delay inform to the gateway (see figure 4 and 
column 12, lines 10-35). Also, Davies teaches how the gateway and terminal 
exchanges the parameter information through the RTCP signals (see figure 10). So 
figure 10, states how the gateway can send a RTCP SR report with time parameter 
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information to the terminal and once the terminal receives that information, the terminal 
calculates its own delay parameter information. Then terminal sends a RTCP RR report 
with delay parameter information added on to the time parameter that the gateway sent 
to the terminal in order to synchronize the gateway and terminal (column 16, lines 10- 
40). Since column 12 teaches that the parameter that sends to terminal is the video 
delay, the parameter tgo in the RTCP SR report can be the video delay information. 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to have the terminal receives video delay information from the 
gateway (server) as taught by Davies to determine the decoder buffer information in the 
client of Haraumoto and Colavito in order to improve network efficiency by calibrating 
and synchronizing the gateway/server to the terminal (Davies: column 1 1 , lines 25-41 ). 

With regard to claim 13, Harumoto teaches (see figures 3, 9, and 12): A 
streaming client, comprising: a pre-decoder buffer (reception buffer, 505) for storing a 
packet stream from a server (page 6, paragraph 121); a media decoder (playback 
module, 510) for decoding the packet stream (page 6, paragraph 122); a buffer 
controller (CPU, 503) for estimating packet stream transfer delay variation (calculating 
TS), and for estimating parameters of a jitter buffer based on the packet stream transfer 
delay variation (calculates delta which is the buffer occupancy at varies TS times: see 
figure 9, paragraphs 174-178) and a signaling engine (transmission/reception module, 
507) for providing information indicative of an aggregate of the pre-decoder buffering 
parameters and the jitter buffer to the server (See steps 301 in figure 1 2, discussed in 
paragraph 182; wherein the terminal calculates (estimates) its own buffer occupancy 
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and then sends its sum of its occupancy to the server. Also, Harmoto teaches in figure 
21 B (see paragraphs 1 7-1 9), how the buffer occupancy is based of the amount of data 
in the video/decoder buffer + reception buffer. ). 

Harumoto fails to disclose that packet stream transfer delay variation indicative of 
a variation time for transferring of the packet stream from the server to the client. 

However Colavito teaches an adaptive jitter buffer management system that 
updates the buffer threshold by calculating the average packet transit time over the 
network and uses that information to determine the jitter in the network in order to 
reduce playout delay and improve quality of service (see abstract and figure 5, steps 
506-512.). 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to have the client/terminal determine the average (estimate) 
packet transmit time over the network (from server to client) as taught by Colavito in the 
transmission/reception module of Harumoto in order to reduce playout delay and 
improve quality of service. 

Harumoto and Colavito fails to disclose receiving from a server pre-decoder 
buffering parameters to ensure that the client is able to play out the packet stream 
without buffer violation when the packet stream is transmitted over a constant delay, 
reliable transmission channel. However, Harumoto teaches how the client knows that 
decoder buffer size is 224 Kbytes and it must have uses a vbv delay in order to play the 
video on the client at a constant rate (paragraphs 8-1 1 ), but it fails to teach the client 
knows this information about the decoder buffer. 



Application/Control Number: 10/623,133 Page 7 

Art Unit: 2467 

Davies teaches a gateway that sends video delay information to a terminal and 
the terminal returning back transit (jitter) delay inform to the gateway (see figure 4 and 
column 12, lines 10-35). Also, Davies teaches how the gateway and terminal 
exchanges the parameter information through the RTCP signals (see figure 10). So 
figure 10, states how the gateway can send a RTCP SR report with time parameter 
information to the terminal and once the terminal receives that information, the terminal 
calculates its own delay parameter information. Then terminal sends a RTCP RR report 
with delay parameter information added on to the time parameter that the gateway sent 
to the terminal in order to synchronize the gateway and terminal (column 16, lines 10- 
40). Since column 12 teaches that the parameter that sends to terminal is the video 
delay, the parameter tgo in the RTCP SR report can be the video delay information. 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to have the terminal receives video delay information from the 
gateway (server) as taught by Davies to determine the decoder buffer information in the 
client of Haraumoto and Colavito in order to improve network efficiency by calibrating 
and synchronizing the gateway/server to the terminal (Davies: column 1 1 , lines 25-41 ). 

With regard to claims 27 and 34, Harumoto et al. teaches (see figures 2, 9 and 
1 2): A streaming server (1 01 ) for transmitting a packet stream to a client device (1 02), 
said streaming server comprising: a signaling engine (a transmission/reception module, 
402) for receiving information indicative of an aggregate of the client's pre-decoder 
buffering parameters and a jitter buffer (See steps 301 in figure 12, discussed in 
paragraph 182; wherein the terminal calculates (estimates) its own buffer occupancy 
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and then sends its sum of its occupancy to the server. Also, Harmoto teaches in figure 
21 B (see paragraphs 1 7-1 9), how the buffer occupancy is based of the amount of data 
in the video/decoder buffer + reception buffer. ), wherein parameters of the jitter buffer is 
estimated based on estimated packet stream transfer delay variation (calculates delta 
which is the buffer occupancy at varies TS times: see figure 9, paragraphs 174-178); 
and a rate controller (CPU, 412: paragraph 120) adapted to adjust a rate at which media 
data is transmitted from the server in accordance with the aggregate buffering 
parameters (see steps 304 or 305 in figure 12: paragraphs 183-186.). 

Harumoto fails to disclose that packet stream transfer delay variation indicative of 
a variation time for transferring of the packet stream from the server to the client. 

However Colavito teaches an adaptive jitter buffer management system that 
updates the buffer threshold by calculating the average packet transit time over the 
network and uses that information to determine the jitter in the network in order to 
reduce playout delay and improve quality of service (see abstract and figure 5, steps 
506-512.). 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to have the client/terminal determine the average (estimate) 
packet transmit time over the network (from server to client) as taught by Colavito in the 
transmission/reception module of Harumoto in order to reduce playout delay and 
improve quality of service. 

Harumoto and Colavito fails to disclose transmitting pre-decoder buffering 
parameters to ensure that the client is able to play out the packet stream without buffer 
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violation when the packet stream is transmitted over a constant delay, reliable 
transmission channel. However, Harumoto teaches how the client knows that decoder 
buffer size is 224 Kbytes and it must have uses a vbv delay in order to play the video on 
the client at a constant rate (paragraphs 8-1 1 ), but it fails to teach the client knows this 
information about the decoder buffer. 

Davies teaches a gateway that sends video delay information to a terminal and 
the terminal returning back transit (jitter) delay inform to the gateway (see figure 4 and 
column 12, lines 10-35). Also, Davies teaches how the gateway and terminal 
exchanges the parameter information through the RTCP signals (see figure 10). So 
figure 10, states how the gateway can send a RTCP SR report with time parameter 
information to the terminal and once the terminal receives that information, the terminal 
calculates its own delay parameter information. Then terminal sends a RTCP RR report 
with delay parameter information added on to the time parameter that the gateway sent 
to the terminal in order to synchronize the gateway and terminal (column 16, lines 10- 
40). Since column 12 teaches that the parameter that sends to terminal is the video 
delay, the parameter tgo in the RTCP SR report can be the video delay information. 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to have the terminal receives video delay information from the 
gateway (server) as taught by Davies to determine the decoder buffer information in the 
client of Haraumoto and Colavito in order to improve network efficiency by calibrating 
and synchronizing the gateway/server to the terminal (Davies: column 1 1 , lines 25-41 ). 
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With regard to claim 2, Harumoto teaches: wherein the pre-decoder buffering 
parameters received are chosen based on variable bit-rate characteristics of the 
transmitted packet stream and the buffering applied by the server (paragraph 171). 

With regard to claims 4, and 20, Harumoto teaches (see figure 4): wherein the 
information indicative of the aggregate buffering parameters is transmitted to the server 
at beginning of a new streaming session (setup is at beginning session, page 6, 
paragraphs 125 and 131). 

With regard to claims 5, 21 , and the first part of claim 33, Harumoto teaches (see 
figure 5) determining parameters of the jitter buffer based on the estimated packet 
stream transfer delay variation during a streaming session and transmitting an 
aggregate of the pre-decoder buffering parameters and the changed jitter buffer during 
the streaming session (repeated s301 after s306: see paragraph 184). 

With regard to claims 7, second part of 33, and 37, Harumoto teaches: wherein 
the streaming server is adapted to optionally consider the information indicative of the 
client's chosen pre-decoder buffering parameters in rate control and/or rate shaping 
(paragraph 190 and 191) 

With regard to claims 8, 22, 31 , and 35, Harumoto teaches: wherein the 
information indicative of the aggregate buffering parameters received by the server 
includes at least one of the following: information regarding a size of the client's pre- 
decoder buffer (paragraph 191), information regarding a pre-decoder buffering period, 
and information regarding a post-decoder buffering time. 
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With regard to claim 15, Harumoto teaches: further comprising a post- 
decoder buffer for storing media data after decoding (see figure 19C: l/P re-order buffer: 
paragraph 09). 

7. Claims 9-1 1 , and 23-25 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Harumoto, Colavito and Davies as applied to claims 1/13above, and 
further in view of Deshpande (US 7,047,308). 

Harumoto teaches a client sending a buffering parameters to SETUP /PLAY 
request command (see figure 4 of Harumoto) before the session starts and after the 
sessions starts (see figure 5 of Harumoto), step 108). And Davies teaches how the 
aggregate parameter information is in RTCP message but Harumoto, Colavito and 
Davies fails to disclose that the those commands are Real-Time Streaming Protocol 
(Play or Ping) messages. 

However Deshpande teaches a system, in which client and server uses RSTP 
messages to communicate and inform with each other about their buffer parameters 
(column 4, lines 55-67). 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to uses any RTSP (play or ping) message to relay buffer 
parameter to the server from the clients as taught by Deshpande in the system of 
Harumoto, Colavito and Davies in order to use a typical streaming media system to 
transmit packet streams (column 1, lines 40-45). 
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8. Claims 16-17are rejected under 35 U.S.C. 103(a) as being unpatentable over as 
applied to claims 13/15 above, and further in view of Radha et al. (US 6,700,893). 

With regard to claims 16-17, Harumoto, Colavito and Davies fails to disclose that 
the pre-decoder buffer and the jitter buffer are implemented as a single buffer unit. 

Radha teaches a similar system of a server sending a packet stream to a client. 
Radha teaches a client device that has a pre-decoder buffer (ITD buffer) and a decoder 
(see figure 1 : column 5, lines 45-60). Similar to Harumoto, the client device has a buffer 
controller (buffer management circuit, 510) that estimates delay, jitter, and bandwidth of 
the network (column 12, lines 20-35). However, Radha also teaches how parameter 
(listed above) may be from the streaming video transmitter, 110, (server). The 
examiner views the ITD buffer as contain both the jitter buffer and the pre-decoder 
buffer since the ITD buffer transmits data to decoder and handles jitter from the network 
(column 9, lines 1-11). 

Therefore it would have been obvious to one having ordinary skill in the art at the 
time invention was made to have the a single buffer unit to be a jitter buffer and a pre- 
decoder buffer as the ITD buffer taught by Radha in the system of Harumoto, Colavito 
and Davies in order to improved streaming data receivers (Radha: column 2, lines 35- 
40). 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to MARCUS R. SMITH whose telephone number is 
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(571)270-1096. The examiner can normally be reached on Mon-Thurs: 8:30 am - 5:00 
p.m. and Friday is a telework day. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Pankaj Kumar can be reached on 571 272-301 1 . The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

MRS 8/13/10 

/Michael J. Moore, Jr./ 

Primary Examiner, Art Unit 2467 



